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1  Introduction 

1.1  Background 

SecureCore  is  a  research  project  funded  by  the  National  Science  Foundation  (NSF)  to 
investigate  the  fundamental  architectural  features  required  for  trustworthy  operation  of 
mobile  computing  devices  such  as  smart  cards,  embedded  controllers  and  hand-held 
computers.  The  goal  is  to  provide  secure  processing  and  communication  features  for 
resource-constrained  platforms,  without  compromise  of  performance,  size,  cost  or  energy 
consumption.  In  this  environment,  the  security  must  also  be  built-in,  transparent  and 
flexible. 

This  document  describes  the  requirements  for  building  extension  modules  that  may  be 
incorporated  into  the  Trusted  Management  Layer  (TML),  specifically  the  Least  Privilege 
Separation  Kernel  (LPSK).  The  LPSK  is  composed  of  modules  which  are  used  as  the 
building  blocks  of  the  kernel  implementation.  These  modules  are  referred  to  as  core 
kernel  modules.  Kernel  extension  modules  are  separate  from  the  core  LPSK  modules, 
providing  additional  functionality. 

A  description  of  the  SecureCore  software  architecture  and  definitions  can  be  found 
elsewhere  [1].  This  document  assumes  the  reader  is  familiar  with  the  architecture  and 
tenninology  of  the  SecureCore  project. 

2  Kernel  extension  modules 

Kernel  extension  modules  are  functionality  outside  the  LPSK  that  need  to  execute  within 
the  same  environment  (e.g.  privilege  level  0,  PLO)  as  the  LPSK.  Kernel  extension 
modules  will  be  developed  and  maintained  separately  from  the  LPSK,  and  will  be 
combined  with  the  LPSK  at  build  time,  during  the  link  phase. 

2.1  Layering 

Sound  software  engineering  practices  require  that  a  system,  such  as  the  LPSK,  be 
decomposed  into  individual  modules,  and  that  these  modules  be  organized  into  ordered 
layers,  such  that  modules  can  only  depend  upon  (e.g.  call  into)  other  modules  in  lower 
layers.  The  goal  of  this  design  methodology  is  to  avoid  circular  call  sequences.  The 
layering  and  modules  are  shown  in  Figure  1. 
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Figure  1.  Modules  and  Layering 

Modules  A,  B,  and  C,  may  call  into  all  modules  in  lower  layers,  layers  below  ‘layer  x’. 
Similarly,  modules  K,  and  L,  may  call  into  layers  below  ‘layer  n’.  Modules  X,  Y,  and  Z, 
are  in  the  lowest  layer  and  may  not  call  into  any  other  modules. 

Kernel  extension  modules  must  be  designed  with  this  layering  in  mind.  Kernel  extension 
modules  must  be  placed  in  a  layer  that  is  1)  above  all  the  modules  upon  which  they 
depend,  and  2)  below  the  modules  that  depend  on  the  kernel  extension  module.  This  is 
shown  in  Figure  2. 
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Figure  2.  Layering  of  Kernel  Extension  Modules 

2.2  Segment  requirements 

The  code  and  data  for  kernel  extension  modules  must  be  in  segments  separate  from  the 
core  kernel  modules.  The  stack  segment  will  be  shared  by  the  core  kernel  modules  and 
the  kernel  extension  modules.  The  kernel  extension  modules  must  have  at  least  one  code 
segment,  but  may  be  composed  of  more  than  one  code  segment,  and  may  have  one  or 
more  data  segments. 

In  the  following  examples  the  unique  identifier  for  the  kernel  extension  module, 
kernel  jnod_name,  does  not  have  to  be  consistent  across  an  entire  kernel  extension 
module.  All  code  blocks  with  the  same  unique  identifier  will  be  combined  into  a  single 
code  segment  and  all  data  blocks  with  the  same  unique  identifier  will  be  combined  into  a 
single  data  segment. 

2.2.1  Code  segments 

To  place  kernel  extension  module  C-language  code  into  its  own  segment,  the  code  must 
be  specified  to  be  in  a  code  segment  other  than  the  default  code  segment.  This  is 
accomplished  by  enclosing  all  code  within  a  ‘pragma  code  seg’  block,  as  follows: 

#pragma  code_seg  (  " kernel  jnodjiame"  , ' ' kern eljn od_n am e_C O D E "  ); 

Kernel  extension  module  code  goes  here 


#pragma  code_seg  (); 
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where  kernel jnodjiame  is  replaced  by  a  unique  identifier  for  the  kernel  extension 
module. 

More  than  one  code  segment  can  be  created  by  having  multiple  ‘pragma  code  seg’ 
blocks,  each  with  a  unique  identifier. 

For  assembly  language  implementations,  the  following  is  used  to  place  code  within  a 
specific  code  segment: 

TEXT  segment  para  public  'kernel jnodjiame  CODE' 

Kernel  extension  module  code  goes  here 


TEXT  ends 

where  kernel  jnodjiame  is  replaced  by  a  unique  identifier  for  the  kernel  extension 
module. 

More  than  one  code  segment  can  be  created  by  having  multiple  ‘segment/ends’  blocks, 
each  with  a  unique  identifier.  To  specify  multiple  code  segments  the  ‘label’  (  TEXT  in 
the  above  example)  would  have  to  be  unique  for  each  code  segment  (e.g.  TEXT01, 
TEXT02). 

2.2.2  Data  Segments 

Kernel  extension  module  data  must  be  put  into  a  data  segment  separate  from  the  core 
kernel  module  data,  using  the  ‘-nd’  compile  switch  (see  Compilation  requirements 
below).  Optionally,  kernel  extension  module  data  may  be  placed  into  more  than  one  data 
segment  by  enclosing  all  C  data  declarations  within  a  ‘pragma  data  seg’  block,  as 
follows: 

#pragma  data_seg  (  "kernel jnodjiame"  ); 

Kernel  extension  module  data  declarations  go  here 


#pragma  data_seg  (); 

where  kernel  jnodjiame  is  replaced  by  a  unique  identifier  for  the  kernel  extension 
module. 

More  than  one  data  segment  can  be  created  by  having  multiple  ‘pragma  data  seg’  blocks, 
each  with  a  unique  identifier. 

For  assembly  language  data  declarations,  the  following  is  used  to  place  data  within  a 
specific  data  segment: 


Trustworthy  Commodity  Computation  and  Communication 


4 


SecureCore  Software  Architecture:  TML  Kernel  Extension  Module  Integration  Guide 


DATA  segment  para  public  ' kernel _mod_name_ DATA' 

Kernel  extension  module  data  goes  here 


DATA  ends 

where  kernel  mod  name  is  replaced  by  a  unique  identifier  for  the  kernel  extension 
module. 

More  than  one  data  segment  can  be  created  by  having  multiple  ‘segment/ends’  blocks, 
each  with  a  unique  identifier.  To  specify  multiple  data  segments  the  ‘label’  (  DATA  in 
the  above  example)  would  have  to  be  unique  for  each  data  segment  (e.g.  DATA01, 
DATA02). 

2.3  Compilation  requirements 

The  core  kernel  module  data  and  constants  must  be  separate  from  the  kernel  extension 
module  data  and  constants.  The  Open  Watcom  compiler  has  a  switch  that  enables  this 
functionality.  Kernel  extension  modules  must  be  compiled  with  the  same  compiler 
switches  as  the  core  kernel  modules  with  the  following  additional  switch: 

-nd =kernel_mod_name 

where  kernel  mod  name  is  replaced  by  a  unique  identifier  for  the  kernel  extension 
module. 

The  ‘-nd’  switch  causes  the  compiler  to  create  a  default  data  segment  that  is  unique  to  the 
kernel  extension  module.  This  data  segment  will  contain  all  data,  constants,  string  literals, 
and  uninitialized  data  associated  with  the  kernel  extension  module. 

2.4  Interfaces 

The  kernel  extension  modules  must  provide  a  header  file,  or  files,  declaring  all  functions 
within  the  kernel  extension  module  that  the  core  kernel  modules  are  expected  to  call. 
Likewise,  the  core  kernel  modules  will  provide  a  header  file,  or  files,  declaring  all 
functions  that  are  exported  to  kernel  extension  modules. 


2.5  Linking 

The  TML  is  linked  using  the  Open  Watcom  linker.  When  linking  the  TML,  the  core 
kernel  module  objects  must  be  first  in  the  list  of  objects  to  link,  followed  by  the  kernel 
extension  modules.  The  linking  will  combine  all  the  object  code  (.0  files)  for  the  core 
kernel  modules  with  the  object  code  for  the  kernel  extension  modules  to  create  the  LPSK 
executable.  The  developers  of  the  kernel  extension  modules  do  not  need  to  be  concerned 
with  the  linking  step,  but  rather  simply  concentrate  on  providing  the  kernel  extension 
module  object  files. 
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